Large mainframe computers have been in wide use for decades. These computers often include a communications system so that multiple users can access and operate the computer simultaneously.
A typical arrangement includes a single mainframe computer located in a computer room. Dozens, if not hundreds, of users are each provided with a computer terminal on their desktops in their own offices. The mainframe computer simultaneously services plural users, each of which is provided with his/her own terminal. These mainframe computers usually are equipped with a multi-tasking operating system such as CICS (an IBM system), UNIX (an AT&T product), or other such operating system.
In recent years, during which the price of personal computers (PC) has drastically been reduced, it has become common practice to replace the user terminals with a PC. The PC includes numerous layers of software which work together so that the personal computer appears to the mainframe like a terminal. The PC however, has capabilities far beyond that of a standard "dumb" terminal.
An exemplary terminal emulation arrangement is described in the publication "IBM Personal communications/3270 Version 3.1--Installation and User's Guide for Full-Function DOS mode". As described at chapter 5 of this publication, the end user of this system may configure certain parameters as desired.
The IBM arrangement contains several drawbacks. First, as noted in the publication, parameters such as screen color, curser style, etc. are in effect "globally". Once the user sets the screen color, for example, it will remain the same for every screen downloaded from the host and displayed on the display. Additionally, the system is not very flexible as the options are limited and are also the same for each user.
The causes of the above drawbacks are best understood by examining the structure of such a system. The personal computer is equipped with several layers of software and hardware, as indicated conceptually in FIG. 1. It is understood that PC 100 may include various other hardware and software components which are not shown in FIG. 1, but which are conventional in the art. Such other components are not critical to the present invention.
The PC 100 runs under its own operating system 105, examples of which are Disk Operating System (DOS), Windows, etc. Communication software 104 serves to implement a predefined communications protocol between PC 100 and a remote host, such that PC 100 appears to the host like a terminal designed specifically to interface with the host.
In operation, a screen of information arrives via communications software 104 and is placed into a buffer 103 for display on the user's screen. In many applications, such as those related to the financial industry, the screen of information usually includes numerous fields, one or more of which may require or allow the user to input data. The fields are displayed on the screen in an order and layout that makes user input of data convenient.
Applications programming interface 102 is a set of programming tools which allows the programmer, among other things, to write applications for retrieving information from buffer 103 and formatting that information before displaying it on screen 101. For example, the programmer may use API 102 to write application programs such that the screen color is different from what it would be if the information was simply displayed from buffer 103 directly onto screen 101. These applications will be termed "display routines" for purposes of explanation hereafter.
Importantly, the APIs may be used so that the alteration performed upon the screen information in buffer 103 is different depending upon the particular screen received and being displayed. Specifically, the screen of information stored in buffer 103 usually contains a screen identification (ID) code comprising several bytes of information in a predetermined location. The screen ID is generated by the application at the remote host, and serves to assist the display routine in identifying which particular screen has been received for display.
For example, consider two possible screen IDs, 123 and 890. Suppose that the screen of information associated with the 123 screen is intended to be read by the display routine from buffer 103, altered in a first manner, and displayed on display 101. Suppose further that the screen of information associated with screen ID 890 is intended to be read from buffer 103 by the display routine and altered in a second and different manner prior to display on display 101.
In order to ensure that the display routine can determine which screen is in fact stored in buffer 103, the screen ID is utilized. The display routine reads the screen ID from buffer 103 and based thereon, determines which screen is stored in buffer 103. After determining which screen is stored in buffer 103, the display routine is programmed to display the information in that screen (e.g.; fields and other data) in a predetermined manner based on several parameters associated with the Screen ID. Of course, in actuality, there would typically be many different screen IDs consisting of numerous alpha numeric combinations.
There are several problems associated with the above described prior art systems. One problem is that every screen downloaded by the host computer into buffer 103 must in fact contain a screen ID in the predetermined field in order to be recognized by the display routine. If no screen ID is present, the display routine does not know how the screen of information should be displayed.
Another major problem with the above arrangement is that if the application is changed, no display or a meaningless display may result. Specifically, suppose that the application running on the remote host were changed so that several fields were removed and/or other fields were added. Suppose further that the screen I, associated with the screen was not modified.
The display routine would simply recognize the screen ID and attempt to display the screen of information in a manner prescribed for a screen with that particular ID. However, the display routine will be looking for fields which are not present in buffer 103 (if these fields have been deleted), or alternatively, will not display fields which are contained within buffer 103 (if fields have been added at the remote application). Other problems may arise if the location of fields on the screen being received from the remote host has changed. In any case, the user may see a screen with missing information, or with information which is irrelevant such as random characters which the display routine believes is meaningful information.
Another severe drawback of the prior art arrangement described above is that solutions are not dynamic. Specifically, consider the case wherein a programmer writes a display routine using an API 102. If the remote application at the host is changed, the display routine must be rewritten to (i) recognize new fields and (ii) not display fields which are no longer present. Additionally, new programming at the host application may be required in order to provide a new screen ID number.
In view of the above, it can be appreciated that there a exists a need in the prior art for improvements which provide easy integration and display of numerous screens, flexibility to the user, and simple straightforward user customization.